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VIP: A Protocol 
Providing Host Mobility 


Computer networks such as the 
Imi'iiK'i have spread worldwide, 
(.ompuiers are getting smaller and 
smaller. Such an environment 
allows users to carry portable com¬ 
puters and use them to access net¬ 
works. "Mobile Computing" has 
become a buzzword in the area of 
computer communications. A vital 
issue in the Held of mobile comput¬ 
ing is how to communicate with 
hosts that move between subnet¬ 
works.' In conventional network 
architectures such as TCP/IP and 
the OSI seven-layer model, the net¬ 
work address of a host denotes its 
identification as well as its location. 
Since host migration results in a 
change of its network address, net¬ 
work addresses returned by name 
servers cannot identify migrating 
hosts. Additionally, communication 
channels cannot be preserved after 
migration. 

There are several candidate proto¬ 
cols for supporting host mobility in 
the Internet [4. 8, 10, 16]. In addition 
to the schemes for the Internet, a 
scheme is proposed for ISO CLNP 
(Connectionless-mode Network Pro¬ 
tocol) networks [2], while another 
scheme uses learning bridges [9]. 
Packet radio networks also support 
host mobility otflj^wjthiiV a subnet¬ 
work [6]. However/tfiftse protocols all 
suffer various problems, e-g-. [4] an£ ^ 
[9] cannot scale to the size of the net¬ 
work: network partitioning might 
disable communications between two 
hosts on the same Ethernet when at 
least one of the hosts is mobile in [16]; 
the schemes proposed in [8] and [10] 
cannot be applied to datagram com¬ 
munication in the transport layer. 
Also, a fundamental problem of these 
schemes is the requirement for a net¬ 
work address to identify the location 
of mobile hosts. _ 

1 1» lliis uilicit, u network rders lo >he overall net " 
work. A \nlmeaoork rders to an individual conl- 
ponem network. An oiternel rders m a nctwor 
on whir It Inicmel Protocol (IP) is running as a 
nelwoik hit it [trolmol. 


This article proposes a protocol 
that provides host mobility in the 
Internet, VIP (Virtual Internet Proto- 
rol). In contrast lo oilier schemes, 
VIP introduces logical identifiers im¬ 
mobile hosts. VIP was first proposed 
in 1991 [18. 14] anti improved in 
1998 [15]. VIP is defined as an in¬ 
stance of the Virtual Network Protocol, a 
network layer protocol that provides 
the transport layer with host migra¬ 
tion transparency anti which is appli¬ 
cable to any connectionless-mode 
network protocol such as IP [7], 
CLNP [5], and Xerox Internet Data¬ 
gram [17], VIP has the following fea¬ 
tures (discussed later): 

• VIP is scalable lo the scale of the 
network anti the total number of 
mobile hosts. 

• VIP is free from routing loops with 
all packets, except for the lirsi packet, 
traversing the optimum route, and 

• VIP is also tolerant ol the loss of 
control packets. 

The Key Services for Host 
Migration Transparency 
Types of Host Migration 
Host migration can be classified into 
two types: off-line and on-line. In on¬ 
line migration, the host is discon¬ 
nected from the network before mov¬ 
ing. In contrast, on-line migration al¬ 
lows a host to access die network even 
during actual movement. In conven¬ 
tional wiled networks, only oil-line 
migration is possible due to physical 
restrictions. However, wireless net¬ 
works such as digital cellular tele¬ 
phone systems allow on-line migra¬ 
tion. In this ariicle, hosts that can 
migrate on-line are called mobile hosts, 
while those that can migrate off-line 
only are called portable hosts. The gen¬ 
eral term migrating host is used to de¬ 
note these two host types. 

The Layer To Provide Host Migration 
Transparency 

From a user's viewpoint, it can be 
possible to adiieve host migration 


transparency in the application layer, 
the transport layer, or the network 
layer. In case oflhe application layer 
approach, name server emries Im¬ 
migrating hosts are updated every 
movement. A host that wants to coui- 
niuuicate with a migrating host 
knows the destination address by ac¬ 
cessing die name server. In this ap¬ 
proach, however, on-line migration 
cannot be achieved because commu¬ 
nication channels are broken after 
movement. 

In case of the transport layer ap¬ 
proach. the transport layer reestab¬ 
lishes communication channels every 
movement with the assistance of the 
application layer approach. In this 
approach, if a host detects its move¬ 
ment. it notifies corresponding hosts 
of its new network address, and then 
the communication channels between 
these hosts are reestablished. In gen¬ 
eral, communication channel man¬ 
agement is complicated. This ap¬ 
proach makes ii more complicated, 
besides the overhead of this ap¬ 
proach increases in proportion to the 
number of active communication 
channels. Additionally, this approach 
cannot provide host migration 
transparency in connectionless 
communication. 

In contrast with these approaches, 
adding only two new services to the 
network layer allows host migration 
transparency as described later. From 
a protocol-layering viewpoint, it is 
suitable that the network layer pro¬ 
vides host migration transparency 
because it is responsible to host-to- 
host communication. In other words, 
the transport and higher layers do 
not perceive the notion of host, and it 
is up to the network layer to inaimaiii 
host location. 

Key Services in the Network Layer 
End-to-end communication services 
are provided by the transport and 
lower lavers. To offer host migration 
transparency in end-to-end commu- 









mention services, die billowing four 
services ill ilie transport liner mnsi be 
migration transparent. 

• Cl'-!) iranspori eniiiy addressing. 
The iranspori layer mnsi provide die 
session layer wiili a migration-inde¬ 
pendent idemilier lor die iranspori 
eniiiy. 

• (T-2) tonneciionless-niode conimu- 
nicalion. The irans|)on layer inusi 
provide iranspori-level cnnneciioii- 
less-mode communication (datagram 
service), regardless of migration. 

• (T-b) eonneciion esiablislnneni. 
The iranspori layer mnsi be able 10 
establish transpori-level connections, 
regardless of migration. 

• (1—4) connection-oriented commu¬ 
nication. The iranspori laser must be 
able lo preserve iranspori-lcvel com¬ 
munication during actual moveineni, 
ollcring irans|iori-level connection- 
orienlecl eonnimnicaiion. 

Oil-line migration transparency, 
which mnsi be provided lo boili pori- 
able and mobile liosls, can be sup¬ 
ported by services '/'-/ through T-j. 
On-line migration transparency, re¬ 
quired by mobile hosts, requires all 
four services. 

To support these services in the 
iranspori layer, die network layer 
must have the hollowing six services. 

• (A’-/) Migralioa-traasjaireat host tul- 
drrssiug: provides die transport laser 
with a migration-independent idenii- 
lier Ibr die host. 

• t.X-2) Migratioa-trua\p(ireut roaaee- 
tioaless-auule roanuaidcatioa: oilers uel- 
svork-level connectionless-mode com¬ 
munication regardless of migration. 

• (A'-j) Disconnect request: prepares 
lor a host to leave a subnetwork when 
it is to be disconnected. 

• (A - --/) Disconnect indication: called by 
the data link layer to prej>aflcu> lease 
die current subnetworkemer 
another in on-line migration;.. 

• (X-5) Conner! request: prepares lor 
joining to a subnetwork svhen a host 
is 10 be connected. 

• f.V-fi) Cunnrrl indication: called by 
the data link layer lo prepare lbr join¬ 
ing a host lo anew subnetwork in on¬ 
line migration. 

The services required in tile trans¬ 
port layer are supported by the ser¬ 
vices in the netsvork layer as follows: 
T-l is supported by N-I. T-2 and T-.S 


are supported bs N-l. N-2. N-ll. and 
N-f). 1-4 is supported bs N-2, N-4. 
anti N-6. 

In the network laser. N-‘.f through 
N-C> are supported by the data link 
layer. Therefore. N-l and N-2. i.e., 
migration Irnnsjiarrut host addressing 
and niigratmn-trausfuirrut connection¬ 
less-mode communication. are peculiar 
to the netsvork layer and can be 
thought of as being key services in 
achieving host migration transpar¬ 
ency. Ihe relationships beisveen 
these services are depicted in figure 
I [II]. 

The Virtual Network 

The previous section defined two nct- 
svork layer services that are key to 
liosi inobilitv: 1) migration-transpar¬ 
ent host addressing and 2) migiaiion- 
t runs parent eonneciion less-mode 

coininunicaiion. In order lo achieve 
llic former, the concept of a virtual 
network is iiuroduced. To achieve the 
latter, the propagating-cochc method is 
proposed. 

The concept. The virtual network is 
a logical netsvork that exists on top of 
the actual, or physical, network. Only 
die virtual neisvork is visible to die 
iranspori layer, bach host is regarded 
as ulsvnvs being connected lo die 
same virtual subnetwork, called die 
home subnetwork of the host even il it 
migrates to another physical .subnet¬ 
work. A host has both a virtual network 
address (I A ’-address) and a physitai net- 
work address tl’X-addiess). Since a host 
never migrates in the virtual net¬ 
work. iis VN-address never changes. 
The I’N-athiress of a host indicates 
the location of the host in the phvsiea! 
network and is used for packet rout¬ 
ing. The iranspori layer specifics the 
target host bv its YN-address, no mai¬ 
ler where it migrates to in the physi¬ 
cal network, basically, the l’N- 
address is invisible to tile transport 
layer. The VN-address and l’N- 
address have the same formal. For a 
host, the tallies of both addresses are 
the same when the host is connected 
to its home subnetwork. 

The relationship between the VN- 
address and the I’N-address of a host 
is analogous to that between the vir¬ 
tual and physical addresses in a vir¬ 
tual memory system. In a virtual 
memory system, the virtual address 
used in a program never changes, no 


matter where the program is located 
in physical memory. .Similarly. a host 
can Ik- indicated by its VN-address no 
mailer where the host migrates in die 
physical network. From another 
viewpoint, the virtual network con¬ 
cept introduces host identifiers in addi¬ 
tion to host addresses. The host iden¬ 
tifier specifies "what it is," whereas 
die host address specifies “where it 
is." 

Layering. Since die iranspori layer 
uses die VN-address in the packet 
transmission request to die network 
lay er, lo deliver packets, the network 
layer must resolve the VN-address of 
a host into the corresponding I’N- 
address. The network layer is respon¬ 
sible for host-to-host eonnimnicaiion, 
including packet relaving, routing 
control, and so on. Since it is not ap¬ 
propriate tu classify this address reso¬ 
lution into the traditional categories 
of basic network layer fin id ions, die 
network layer should be divided iiuii 
two snblavers. as follows (see Figure 
2 ): 

• The virtual artwork sublayer (l '.V- 
sidiluyrr) conceals the physical location 
o( hosts in die phvsical subnetworks. 
A host is assigned a VN-address. 
which tile VN-snblaycr resolves into 
the corresponding I’N-address. 

• The physical artwork sublayer fl’i V- 
suhlayrr) is the conventional network 
laser. According to the OSI layering 
model, this sublayer consists of die 
snbuei work-independent suhlavcr. 
the subnetwork-depending sublayer, 
and the subnetwork access sublayer. 
The 1’N-sublaver is responsible Ibr 
packet relaving, routing iulnriuaiiou 
exchange, and so on. A host is as¬ 
signed a l’N-address in the l’N- 
snblayer. 

This protocol layering a fleets die 
packet header formal. According lo 
this division..the- VN-sublavcr header 
is added'between the (physical) net¬ 
work laser and iranspori layer head¬ 
ers. if the (physical) network layer 
header of an incoming packet speci¬ 
fies the VN-sublaver as the next 
higher layer, the packet is passed to 
the VN-sublayer. Otherwise, the 
packet bypasses the VN-sublayer and 
is passed to tile transport lay er. Thus, 
the VN-sublayer can be bypassed if 
;m incoming packet does not have the 
VN-sublayer header, or if the receiv- 
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ing host does not support the VN- 
stibliiver and silently ignores the VN- 
stihlaver header. 

The Propagating-Cache Method 
Tile basic idea of the propagating- 
cache method takes advantage of a 
cache mechanism for address resolu¬ 
tion, i.e., each router or host holds a 
cache for address resolution. Address 
resolution is executed either on the 
source host or an intermediate 
router. If the source host does not 
know the I’N-address of the destina¬ 
tion host, it assumes the destination 
host is phvsically connected to its 
home subiie(w<irL_i-e., the sender 
assumes the Ph feutetT ess of the desti¬ 
nation host to be reg nal to its VN* 

address. Then^'-dte.' transmitted 
packet travels to the home subnet¬ 
work of the destination host. How¬ 
ever. if a router on the path holds a 
cache entry for the destination host, it 
resolves the VN-address of the desti 
nation host into the PN-address. 
Then, the packet is forwarded to the 
actual physical location of the destina 
tion host without traveling th e entlf ? 

route to the home subnetwork. 

cache is created or updated using * e 
packets received. Cache information 
propagates across the wide area net 

work along the communication pa* s 

between migrating hosts, such * a 


Figure i. Relationships between services 
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Figure 2. protocol layering fora virtual network 


routing to ;i migrating host becomes 
more ellicicnt as communication be¬ 
tween migrating hosts occurs. 

A host is called a family host on its 
home subnetwork. The relationship 
between the VN-address and the PN- 
address of a family host is always 
maintained by the hosts or routers in 
honte subnetwork. In practice, 
' n g routers in the home subnet- 
work maintain the relationship for 
*he family hosts is sufficient for ad¬ 
dress resolution. 

7,16 Virtual Network Protocol 

77le Virtual Network Protocol (VN-prolo- 
col) is a general protocol that provides 
host mobility on the top of connec¬ 
tionless-mode network layer prof¬ 


its 

hav 


cols. The VN-piotocol exploits the. 
virtual .network concept and the, 
propagating-cache method to achieve 
the two key services defined earlier. 
The cache in (lie propagating-cache 
method is called the Address Mapping 
Table (AMT). The AMT consists of 
entries, each of which corresponds to 
a migrating host. The VN-proioco! 
has two control packet types: CAMT 
(create an AMT entry) and InvAMT 
(invalidate tin AMT entry). A data 
packet as well as the CAMT packet 
creates or updates an AMT entry 
when relayed or received. A router 
that executes address resolution is 
called an address resolver. Address 
resolution for a packet destined 
*o a migrating host is executed by 
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Figure «. Data communication 


eillier the source Iiosi or an address 
resolver. 

Address Resolvers 

There are three types of" address re¬ 
solvers for each migrating host: )m- 
wan address re\nl\>er. serondan address 
resolver, and Irw/unan /irnxx. A pri¬ 
mary address resolver is an address 
resolver in die home su.lyngTfdrkmf a 
migrating host. The pritwarySaddress 
resolvers for a migrating~hmi,always 
hold the most recent AMT'entry lor 
tlie migrating host. A secondary ad¬ 
dress resolver is an address resolver 
in the subnetworks other than the 
home subnetwork of die migrating 
host. Obsolete AMT entries might 
remain on secondary address resolv¬ 
ers. A temporary proxy is a kind of 
secondary address resolver in the 
subnetwork to which the migrating 
host was previously connected. The 
temporary proxy was introduced (or 


remapping of [jackets that suffered 
incorrect mapping for the destination 
host by an obsolete AMT entry. 

Connecting to a Subnetwork 
Figure 3 depicts the packet flow when 
a migrating host connects to a subnet¬ 
work. I) Tbe migrating host trans¬ 
mits a CAMT packet to its home sub¬ 
network. On relaying this CAMT. 
packet, intermediate routers create 
or update the AMT entry for the mi¬ 
grating host, i.e., such intermediate 
routers become secondary address re¬ 
solvers for the migrating host. While 
connected to a subnetwork other 
than the home subnetwork, the mi¬ 
grating host continues to transmit a 
("AMT packet periodically. 2) If an 
intermediate router holds an obsolete 
AMT entry for the migrating host, it 
broadcasts an InvAMT packet to all 
the connected subnetworks to invali¬ 
date any obsolete entries that might 


remain on other routers. When a 
router receives such an InvAMT 
[jacket, if it holds an obsolete AMT 
entry, it invalidates that entry and 
broadcasts the InvAMT packet. Note 
that (lie InvAMT packet is not broad¬ 
cast throughout since a host or router 
does not forward an InvAMT [jacket 
if it rloes not have the corresponding 
entry or holds a newer entry. 3) 
When a primary address resolver of 
the migrating host receives this 
('.AMT packet, it also creates or up¬ 
dates the AMT entry for die migrat¬ 
ing host. If it holds an obsolete AMT 
entry for the migrating host, it trans¬ 
mits another CAMT packet to the 
subnetwork to which the migrating 
host was previously eoimected. As a 
result, the previous subnetwork holds 
the most recent AMT entry lot- the 
migrating host until it times out, i.e., 
the previous subnetwork becomes a 
temporary proxy lor the migrating 
host. 4) On the path of the CAMT 
packet transmitted by a primary ad¬ 
dress resolver, the same processing as 
2) is executed. 

Data Communication 
Figure 4 depicts the possible How of 
packets in data communication. 
There are lour eases: a) If the source 
host has the AMT entry for the desti¬ 
nation host, it executes address reso¬ 
lution. The [jacket will traverse the 
optimum route, b) If the smiree host 
does not have the AM'F entry for the 
destination host, it assumes that the 
I’N-address of the destination host is 
ei|uu! to its VN-address. "Fite packet 
heads for the home subnet work of 
the destination host. If an intermedi¬ 
ate router holds an AM'F entry for 
the destination host, it executes ad¬ 
dress resolution and forwards the 
packet, r) A primary address resolver 
receives ultimately the packet head¬ 
ing for the home .subnetwork of the 
destination host. It executes address 
resolution and forwards the packet, 
d) A router that holds an obsolete 
AM'F entry for the destination host 
executes address resolution for the 
packet heading for the home subnet¬ 
work of the destination host. 'Fite 
[jacket is forwarded to tbe previous 
subnetwork of the destination host. A 
temporary proxy of the destination 
host in the previous subnetwork exe¬ 
cutes address resolution and for- 
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wards the packet to the correct loca¬ 
tion. Note that once the source host 
receives a packet from the destination 
host, it creates the AMT entry for the 
destination host. 

If a host does not have the func¬ 
tions for the VN-protocoI. it transmits 
conventional network layer packets. 
When a router relays such a packet, if 
it has tile AMT entry for the destina¬ 
tion host of the packet, it adds the 
VN-sublayer header to the packet 
and forwards it. In the worst case, 
such a packet reaches the primary 
address resolver of the destination 
host and is converted into a VN- 
protocol packet. When such a host 
receives a VN-protocoI packet, if it si¬ 
lently ignores tile header of the VN- 
sublayer, it correctly recognizes the 
VN-address of the source host. (Such 
a case in the II’ environment is dis¬ 
cussed later.) 

Disconnecting from a subnetwork 
Figure 5 depicts the packet flow when 
a migrating host disconnects from a 
subnetwork or is powered off. I) The 
migrating host may transmit an In- 
vAMT packet to its home subnet¬ 
work. Note that the migrating host 
can omit this procedure. 2) On the 
path of the InvAMT packet, if an in¬ 
termediate router hits an obsolete 
AMT entry for the migrating host, 
the router broadcasts another In¬ 
vAMT packet to all connected subnet¬ 
works. When a. router receives such 
an InvAMT packet, if it holds an ob¬ 
solete AMT entry, it invalidates that 
entry and broadcasts the InvAMT 
packet, 3) When a primary address 
resolver of the migrating host re¬ 
ceives the I nvAMTjtacket, it if has an 
obsolete AMT entry? for the host, it 
broadcasts anothref~I.nvAMT packet 
to all connected subnetworks. 

The VN-Protocol Header 
As mentioned earlier, the network 
layer header includes both the VN- 
sublayer header and the PN-sublayer 
header. The PN-sublayer header is 
equal to the conventional networ 
layer header. The VN-sublayer 
header must have the following 
fields: Flags, Source VN-address/P 
address/Atldress-Version, Destination 
VN - address/PN - address/Address- 
Version, Holding Time, Resolver PN- 
address. Target VN-address/PN- 


address/Address-Version, and Target 
Holding Time. The Flugx field speci¬ 
fies the packet type and other infor¬ 
mation. There are three packet types: 
data, CAMT, and InvAMT. The 
Holding Time field in the data packet 
specifies the timeout value of the 
AMT entry created or updated by 
this packet. The Resolver PN-acldress 
field in the data packet specifies the 
PN-address of the address resolver 
that executed address resolution for 
this packet. The Target VN-address/ 
; PN-address/Address-Version fields in 
the CAMT/InvAMT packet indicate 
those values of the target machine of 
the AMT entry to be updated. On the 
other hand, in case of the data packet, 
the Source VN-address/PN-address/ 
Address-Version fields are used for 
AMT update. 

AMT Entry 

The AMT must hold the information 
that enables 1) resolution of the VN- 
address of the destination host into 
the corresponding PN-address, 2) 
keeping the entry consistent with the 
most recent information, and 3) dele¬ 
tion of itself when it has not been re¬ 
freshed for a certain period. Thus, an 
AMT entry must have the following 
five fields: Virtual Network Address, 
Physical Network Address, Address 
Version Number, Status, and Hold¬ 
ing Time. 

An AMT entry takes one of three 
states: free, valid, and invalid. In the 
free state, the entry does not hold any 
information. When relaying or re¬ 
ceiving a packet, if the host does not 
have an AMT entry for the source 
host of the packet or it has an older 
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entry for the source host, it creates or 
updates a valid entry. In the valid 
state, the entry holds a valid mapping 
between a VN-address and a PN- 
address. A valid entry overwrites the 
destination PN-address field when 
relaying a packet which holds an 
older mapping for the destination 
host. When the entrv times-out. it re¬ 
turns to the free state. A valid entry 
changes its slate to invalid when re¬ 
ceiving an InvAMT packet which has 
an equal or newer version number 
than the entry. A valid or invalid 
entry detects an obsolete mapping Tor 
the destination host which might be 
caused by an obsolete AM I' entrv on 
another machine. Invalid entries are 
used not for address resolution hut 
for detecting packets that have an 
obsolete mapping between the desti¬ 
nation VN/PN-addresses. When a 
host or router delects an obsolete 
mapping in a packet, it transmits an 
InvAMT packet to the address re¬ 
solver indicated by the Resolver PN- 
address field of the packet. The rea¬ 
son why the invalid state was intro¬ 
duced is to increase the probability of 
detecting obsolete mappings. An in¬ 
valid entry times-out also, and then 
changes its state to free. Such deletion 
of the AMT entry (valid —► invalid —► 
free) is called the lu'ii-jilwsril tlrlrlinn. 
Figure 6 depicts the state transition 
diagram of an AMT entry. 

VIP: Virtual internet Protocol 

VIP is derived from IP by applying 
the VN-protocoI. VIP /iil/lirssfx are 
introduced as VN-addresses in the 
VN-proiocol, while IP addresses are 
thought of as PN-addresses. Table 1 
shows the correspondence of the VN- 
prottKoI to VI.P. 

VIP Header and AMT Entry 
Figure 7 depicts the VIP header for¬ 
mats. Figure 8 shows tile format of an 
AMT entry for VIP. Since the length 
of the VIP header becomes too great 
if it includes all mandatory fields for 
the VN-sublayer header, the control 
packet is separated from the data 
packet. To ensure backward compati¬ 
bility with IP, the VIP header is im¬ 
plemented as an IP option, instead ol 
the higher-sublaver header oflP[I2]. 
In Figures 7(a) and (b), the top-20 
octets construct the IP header, while 
the remainder is the VIP header as 
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Table i. Correspondence of the VN-protocoi to viP 


VN-prolocol 

VIP 

VN-addresses 

VIP addresses 

I’N-addresses 

IP addresses 

home subnetwork 

the subnetwork indicated by the network 
number of the VIP address 

primary address resolvers 

routers connected to the home subnetwork 
of a migrating host (home routers) 

secondary address resolvers 

routers connected to the subnetworks other 
than the home subnetwork of a migra¬ 
ting host 

temporary proxies 

routers connected to the previous subnet¬ 
work of a migrating host 


;in II’ option. In accortlunce with the 
il’ option format, the VII’ header in¬ 
cludes the Option Type and Length 
fields. Note that the Source VII’ Ad¬ 
dress held is included in the 11’ 
header and that the Source II’ Ad¬ 
dress field is included in the VII’ 
header to ensure backward compati¬ 
bility with IP. 

To control address resolution and 
the manipulation of AM T entries, 
VII’ defines four more Hags in the 
Flags field of the VIP header in addi¬ 
tion to the Hags indicating the packet 
type (see Figure 7(c)). If the don't 
cache Hag is set. routers other than 
the home routers of the source host 
do not create the AMT entry for the 
source host. If the don't resolve Hag is 
set, routers other than the home 
routers of the destitution host do not 
execute address resolution for the 
destination host. II the aniheniicaiion 
flag is set. the packet includes authen¬ 
tication dam. If the broadcast In- 
vAMT Hag is not set. routers do not 
broadcast an InvAMT packet on de¬ 
tecting obsolete AMT entries. 


Examples 

Figure !) shows a simple Internet con¬ 
sisting of both VIP and IP machines. 
In the figure, a VIP host Hnst:A-a 
moves from its home subnetwork 
Net:A-b to Nci.B-a (I). 'File VIP ad¬ 
dress of Hosr.A-a remains unchanged 
while it temporary IP address is as¬ 
signed to the host by, say, DHCP (Dy¬ 
namic Host Configuration Protocol) 
|.‘ij. Hnxi:A-a transmits a GAMT 
packet to its home subnetwork Net:A- 
b, so that intermediate VIP routers 
(CWtlL GU':BB-ab. and C\\':A) and 
its borne routers (G\V:A-ab and 
G\V:A-he) create an AMT entry for 
Hosn.A-a. Consider packet transmis¬ 
sion front a VIP host HoscC-a to 
Host:A-a. Since Host:C-a does not 
have the AMT entry litr Hosr.A-a. it 
assumes that the IP and VIP ad¬ 
dresses of Hosi:A-;i are the same. 
Therefore, the VIP packet heads for 
Net:A-h. On relaying the packet on 
G\\':BB-ab, since it lias the AMT 
entry for Host:A-a, it executes ad¬ 
dress resolution and forwards the 
VIP packet to Net:B-a. An IP host 


Host:C'.-b transmits an IP packet to 
liosl:A-a with the VIP address of 
Host:A-a as the destination IP ad¬ 
dress. This IP packet is converted 
into a VIP packet by G\V:BB-ab and 
forwarded to Nct.B-a. Note that once 
HoscC-a receives a VIP packet from 
Host-A-a, it creates the AMT entry for 
Hosi:A-a. such that it executes ad¬ 
dress resolution at the transmission 
time. However, packets transmitted 
by Hosi:C-b always travel the redun¬ 
dant route. 

Suppose that Hosr.A-a moves 
again from Net:B-a to Nei:A-c (2) and 
that its home routers and GW:D hold 
an AMT entry for Host:A-a, which 
indicates tbiti the current subnetwork 
of Host:A-a is Nei:B-a. When Ht>si:A- 
a transmits a CAMT packet to its 
home subnetwork, C\V:A-ltc also 
transmits another CAMT packet to 
Nci:B-a because G\\’:A-bc held an 
obsolete AMT entry. As a result, 
GW'.B updates the AMT entry for 
Host:A-a. i.e., it becomes the tempo¬ 
rary proxy of Hosr.A-a. However, an 
obsolete AM'F entry for Host:A-a 
remains on G\\':D. Consider the 
packet transmission from a VIP host 
Host:I)-a to Hosr.A-a. The VIP 
[Jacket transmitted by Host:D-a is for¬ 
warded to Net:B-a because OW-D hits 
an obsolete AM’F entry for Hnsi:A-a. 
Since G\V:B has the must recent AM'F 
entry for Hosi:A-a. it executes correct 
address resolution and forwards the 
[jacket to NcnA-c. G\V:B also trans¬ 
mits an InvAMT [jacket to G\\’:l> to 
invalidate the obsolete AMT entry. A 
new. correct AM'F entry will he cre¬ 
ated at G\V:D if Hosr.A-a sends a 
reply to Hosr.D-a. 

Discussion of VIP Features 
Scalability on Memory usage 
Although .VIP- makes use of a cache 
called-the--A'MT for-address resolu¬ 
tion. the number of AMT entries a 
host or router must maintain is inde¬ 
pendent of the scale of the internet or 
the total number of migrating hosts. 
It is suHicicnt for a host to have AM'F 
entries for oilier hosts with which the 
host communicates. If a Host commu¬ 
nicates with up to 100 hosts simulta¬ 
neously, it is enough for the host to 
have 100 AMT entries, which occupy 
only 2,800 octets.’’ 

The number of AMT entries a 
router must maintain is equal to the 
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Figure 6. State transition diagram of an AMT entry 
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Figure 11 . Comparison of processing time 


numbers compared on address reso¬ 
lution and AMT entry update a. ecre- 
it ated by the same host, the coinpari- 
uter SC)n () l version numbers always works 
ter l '‘ >n ectl >'. provided eadi Iiost ensures 
■ hat its address version number in¬ 
creases monotonically. 

Routing Loops 

VIP is a protocol which resolves a 
^ ^ addiess into a corresponding II’ 
address. Packet routing is calculated 
in the IP layer. VIP never affects the 
routing calculation in the IP layer. 
Since the comparison of version 
numbers works correctly as men¬ 
tioned earlier, the destination IP ad¬ 
dress of the packet is updated moms 
tomcally as the packet is relayed by 
routers. Therefore, the packet 
reaches a host regardless of whether 
r ,l,e 'c-ceiving bos. is the correct desti¬ 
nation host. Consequently, as long as 
v ihe routing control in the IP laver is 
; free from routing loops, VIP will 
c never exhibit routing loops. 

. Loss of Control Packets 

1 here are two control packet types 
for VIP: (.'AMT and InvAMT. VIP is 
tolerant of losing control packets. 
Since a migrating host continues to 
transmit CAMT packets to its home 
subnetwork periodically, the loss of a 
single CAMT packet is not fatal. An 
IitvAMI packet is transmitted when¬ 
ever an obsolete AMT entry is found. 

It may be transmitted also when a 
Iiost is about u> disconnect from a 
subnetwork or when the host is pow¬ 
ered off. If an InvAMT packet is lost, 
obsolete AMT entries will time-out. 
Kven il an obsolete AMI entry deliv- 
eis a \ IP packet loan incorrect host, 
the receiving host can detect the mis¬ 
delivery because the destination VIP 
address of the packet does not match 
the VIP address of the host. 

Network Partitioning 

There is the possibility that network 
partitioning disables coiiimuiiicaiion 
with a migrating host even if an avail¬ 
able physical link exists. Suppose that 
the network is partitioned between a 
host that is about to send a packet to a 
migrating host and the home subnet¬ 
work of the migrating host. If neither 
the sending host nor intermediate 
routers have the AMT entry for the 
migrating host, the transmitted 
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packet will be lost. However, if the 
migrating host sends packets, AMT 
entries lor the migrating host propa¬ 
gate along the communication path. 
Thus, network partitioning is not 
fatal to VIP. hnt VIP is not tolerant of 
all forms of network partitions. 

Compatibility with IP 
Suppose that a VIP subnetwork is 
connected to a traditional IP network 
anti that a VIP host, whose home sub¬ 
network is the VIP subnetwork, mi¬ 
grates to an IP subnetwork. The VIP 
host can communicate with any IP 
host with its VIP address. VVhen the 
VIP host transmits a VIP packet to an 
IP host, the values in the Destination 
IP and VIP fields of the VIP packet 
will he the same. The VIP packet 
travels the optimal route to the desti¬ 
nation IP host. IP routers and IP 
hosts ignore the VIP header as an 
unknown IP option [Ij. IP routers 
relay the VIP packet correctly, and IP 
hosts handle the VIP packet cor¬ 
rectly. Additionally, since the Source 
IP Address field of the VIP packet 
holds the VIP address of the source 
VIP host instead of its temporary IP 
address, the destination IP host rec¬ 
ognizes the correct source address of 
the VIP packet. 

When the IP host transmits an IP 
packet to the VIP host, the Destina¬ 
tion IP Address held of the IP packet 
is assigned the VIP address of the 
VIP host. This packet heads for the 
home subnetwork of the VIP host. If 
an intermediate router has an AMT 
entry of the VIP host, it converts the 
IP packet into a VIP packet. In the 
worst case, the IP packet reaches the 
home subnetworks off the VIP host, 
then is converted^nfif-a VIP packet. ^ 


BSD/386 on PCs with Intel 386/486). 
The VIP functions were added io the 
IP layer in the kernel. The added 
functionality requires approximately 
900 lines of C code. Figure 10 shows a 
block diagram of the code. In tile 
figure, thin boxes indicate IP mod¬ 
ules while thick boxes indicate VIP 
modules. 

The VIP processing time was mea¬ 
sured by using a special timer board 
with a I-/isec granularity. Our lest 
environment consists of seven SONY 
NEWS workstations and four Ether¬ 
nets. Each workstation has a 
MC68030/25MHz CPU and 4 io 8MB 
of main memory. 

Figure 11 shows the processing 
time required for the transmission, 
relay, and reception of IP and VIP in 
the stable state. "Stable state" means 
that I) the source host has the AMT 
entry for the destination host, 2) in¬ 
termediate routers have the AMT 
entry for the source host and l«>r the 
destination host, and 3) the destina¬ 
tion host has the AMT entry for the 
source host. Therefore, the IP ad¬ 
dress for the destination host is re¬ 
solved at the source host. Intermedi¬ 
ate routers and the destination hosts 
update only the Holding Time field 
of the entry for the source host. Inter¬ 
mediate routers do not modify any 
header field related to the destination 
host, although they search the AMT 
for the entry for the destination host. 
The numbers in parentheses repre¬ 
sent the overhead relative to that of 

The host-to-host overhead of VIP 
can be formulated as a function of the 
hop count, ;l .s follows. 

oi'erhead = 89A,' ; ,„,„ 4- 189 (pisec) 


Thus, packets fronnih IP host to a 
VIP host might travel'along redun¬ 
dant routes. 


— N t 


The VIP overhead is approxi¬ 
mately 0.6 ms if M/,,,!, is 5, 1.0 ms if 


implementation and r 

Performance . 

In general, there are two ways of in¬ 
corporating a new protocol into exist¬ 
ing systems: l) to write programs 
from scratch and 2) to modify exist- . 
ing programs. For the sake of ease o 
implementation and future software 
distribution, the latter was chosen to . 
implement VIP. VIP was imp. e 
mented by modifying 4 . 3 BSD Unix = 
based operating systems (NEWS- 


SONY NEWS workstations 


and 


a* is 10, and 2.0 ms if is 20. 
; Since IP transmission in the Internet 
. takes time on the order of 100 ms. the 
P data packet transmission over- 
_ ca ' s ne gligible from the user's 

viewpoint. 

Conclusions 

TTiis article proposed VIP. a protocol 
h ^osts. VIP is an instance of 

^ ^-protocol, the general proto- 
co Providing host migration trans¬ 
parency [ 0 t | )e transport layer. The 
e y P<)ini of t| le VN-pnitocol is to 


separate logical identifiers from phys¬ 
ical identifiers. In the conventional 
network architecture, each host is 
identified by its location in (lie net¬ 
work. i.e.. bv a physical identifier. 
However, each host should be recog¬ 
nized by a logical identifier because it 
is no longer stationary. This is the 
base of the virtual network concept. 
Such a notion should be applied to 
other identifiers such as group identi¬ 
fiers for multicast communications. 

Currently. VIP is running on a lest 
network. We plan to deploy VIP in 
the WIDE internet' 1 and in a campus 
network of Keio University 1 to deter¬ 
mine tile optimum values for param¬ 
eters such as tile interval time of the 
CAMT packet transmission, the num¬ 
ber of AMT entries, and the value of 
the Holding Time field of the VIP 
header. 

Some problems still remain un¬ 
solved however. One is security. To 
prevent malicious hosts from imper¬ 
sonating others. a host auihenticiUion 
mechanism must be implemented in 
VIP. Security is an area for future 
study. Also, we plan to apply the 
mechanisms of VIP to oilier connec¬ 
tionless-mode network laver proto¬ 
cols such as ISO CI.NP. □ 
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The World-Wide Web 


The World-Wide Web (W3) was 
developed lo lie a pool of human 
knowledge, which would allow col¬ 
laborators in remote sites to share 
their ideas and all aspects of a com¬ 
mon project. Physicists and engi¬ 
neers at C.ERN. the European 
Panicle Physics Laboratory in 
Geneva, Switzerland, collaborate 
with many other institutes to build 
the software and hardware for high- 
energy physics research. The idea of 
the Web was prompted by positive 
experience of a small “home-brew’' 
personal hypertext system used for 
keeping track of personal informa¬ 
tion on a distributed project. The 
Web was designed so that if it was 
used independently for two proj¬ 
ects, and later relationships were 
found between (he projects, then 
no major or centralized changes 
would have to be made, but the 
information could smoothly re¬ 
shape to represent the new state of 
knowledge. This property of scaling 
has allowed the Web to expand 
rapidly from its origins at CERN 
across the Internet irrespective of 
boundaries of nations or disciplines. 

If you haven't yet experienced the 
Web, the best way to find out about it 
is lo try it. An Appendix lo this article 
gives some recipes for gening hold of 
W3 clients. Given otig of these, sou 
will t|uickly find out all you need to 
know, and much more. Tor hard 
copy to read on the plane, or if von 
don't have Internet access from your 
desktop machine, refer to our paper 
in F.lrclmiiit A ' W » v r/.vi ig( s c l*— (lloxsarv 
and further Reading^idSe'.an over¬ 
view of the project. maicemlAyhk'h we 
will not repeat but wifi summarize 
here. 

A W:t ■'clietii" program tints on 
your computer. When it starts, il dis¬ 
plays an object, normally a document 
with text and possibly images. Some 
of the phrases and images are high¬ 
lighted: in blue, or boxed, or perhaps 
numbered, depending on what sort 
of a display yon have and how your 
preferences have been set. Clicking 
the mouse on the highlighted area 


("anchor") causes the diem program 
to retrieve another object front some 
other computer, a “server." The re¬ 
trieved object is normally also in a 
hypertext format, so the process of 
navigation continues (see figure l). 

When viewing some documents, 
the render can request a search, by 
typing in plain text (or complex com¬ 
mands) to send to the server, rather 
than following a link. In either case, 
the client sends a request oil" to the 
server, often a completely different 
machine in some other pari of the 
world, and within (typically) a sec¬ 
ond. the related information, in ei¬ 
ther hypertext, plain text or multime¬ 
dia Inrmai, is presented. This is done 
repeatedly, and by a sequence ol se¬ 
lections and searches one can find 
anything that is "out there." Some 
important things to note are: 

• Whatever type of server, the user 
interlace is the same, so users do not 
need to understand the dilferencex 
between the many protocols in com¬ 
mon use. Before W.'l. access to net¬ 
worked information typically in¬ 
volved knowledge of many dillerent 
access "recipes" lor different systems, 
and a dillerent command language 
for each. The model of hypertext 
with text input lias proved sufficiently 
powerful to express all the user inter¬ 
laces. while being sufficiently simple 
lo ivqnire.no training for a eompnier 
user. 

• Links tail point to anything dial 
can he displayed, including search 
result lists. (When a (piety is applied 
to an object, the resulting object has 
an address, defined to be the address 
of the queried object concatenated 
with the text of the query. As the re¬ 
sult object has an address, one can 
make links to il. Following the link 
later leads to a reevaluation of the 
query.) 

• While menus and directories are 
available, the extra option of hyper¬ 
text provides a more powerful com¬ 
munications tool. In simple cases, die 
server program can generate a hy¬ 
pertext view representing (for exam¬ 


ple) the directory structure of an ex¬ 
isting file store. This allows existing 
data to he pot “on the Web" without 
further bom.in ellorl. 

• There is a very extendable system 
lor introducing new formats for mul¬ 
timedia data. 

• There are many W;l client pro¬ 
grams. As hypertext information is 
transmitted on the network in logical 
(mark-up) form, each client can inter¬ 
pret this in a way natural for the 
given platform, making optimal use 
of louts, colors, and oilier human in¬ 
terlace resources available on that 
platform. 

What Does W3 Define? 

w:l lias come to stand for a number 
of tilings, which should be distin¬ 
guished. These include 

• The idea of a boundless informa¬ 
tion world in which till items have 
a reference by which they can be 
retrieved: 

• The address system (URI) which 
the project implemented lo make this 
world possible, despite many differ¬ 
ent protocols; 

• A network protocol (HTI'l’) used 
bv native W.'l servers giving periltr- 
mance and features not otherwise 
available: 

• A markup language (HTML) which 
every Wll client is required to under¬ 
stand. and is used for the transmis¬ 
sion of basic things such as text, 
menus and simple on-line help inlor- 
maiioii across the net: 

• The body of data available on the 
Internet using-all or some of the pre¬ 
ceding list eel ileitis. 

The client-server architecture of the 
Web is illustrated in figure L’. 

Universal Resource Identifiers 
Universal Resource Identifiers 1 
(URls) are the strings used as ad- 

'Tin* Imernei Kn^iueenn^ Task l-'orc e (IKTH cs 
nmviiilv (Mining ;i siand derived nniiuin 
known as a l ; nilonn KcMium* I-»xaio» (l : RL). 
.•Vs this work is noi ioni|>le<i\ and (lint* is no 
^II.IIIIIIKT lilill I'Kl.S will ll.IVU lllf NHIIK- SVIU.IN 

nr j>ro|>onk*s ns L T RIs, we use the H*rm t’RI liere 
in avoid enniusinn. 
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dresses of objects (e.g.. menus, docu¬ 
ments, images) on liter Web. For ex¬ 
ample, the URI of"tlier main page for 
the WWW project happens to be 

http: //info. cem. ch/hypertext/ 

WWW / TheProj e ct. html 

URls are “Universal" in that they 
encode members of the universal set 
of network addresses. For a new net¬ 
work protocol that litis some concept 
of object, one can form an address for 
any object as the set of protocol pa¬ 
rameters necessary to access the ob¬ 
ject. If these parameters are encoded 
into a concise string, with a prefix to 
identify the protocol and encoding, 
one has a new URI scheme. There 
are URls for internet news articles 
and newsgroups (the NNTP proto¬ 
col), and for I'l l’ archives, for telnet 
destinations, email addresses, and so 
on. The same can he done lor names 
of objects in tt given name space. 

'Fite prefix "Imp” in the preceding 
example indicates the address space, 
and defines the interpretation of the 
rest of the string. The HTIT protocol 
is to be used, so the string contains 
tlie address of the server to be con¬ 
tacted, and a substring to lie passed to 
the server. Different protocols use 
different syntaxes, hut there is a small 
amount of common syntax. For ex¬ 
ample, tlie common URI syntax re¬ 
serves die as a way of representing 
a hierarchical space, and as a sep¬ 
arator between the address of an ob¬ 
ject anti a query operation applied to 
it. As these forms recur in several in- 
formaiion systems, to allow expres¬ 
sion of them in the common syntax 
allows the features to he retained in 
the common model, where appropri¬ 
ate. Hierarchical forms ate useful for 
hypertext, where one,“w o rk" may be 
split up into many'TBtiuTSuked docu¬ 
ments. Relative natuuUiexploii the 
hierarchical siructure-atitFallow links 
to be made within the work indepen¬ 
dent of the higher parts of tite URI 
such as the server name. 

URI syntax allows objects to be 
addressed not only using H'ITI\ but 
also using the oilier common net¬ 
worked information protocols in use 
today (FTP, NNTP, Gopher, and 
WAIS), and will allow extension when 
new protocols are developed. 

URls are central to tlie W3 archi¬ 


tecture. I'he fact dial it is easy 10 ad¬ 
dress an object anywhere on tlie 
Internet is essentia! for the system to 
scale, and for tlie information space 
to he independent of the network 
and server topology. 

Hypertext Transfer protocol 
Perhaps misnamed, rather than 
being a protocol for transferring hy¬ 
pertext, HTFP is a protocol for trans¬ 
ferring information with the effi¬ 
ciency necessary for making 
hypertext jumps. The data trans¬ 
ferred may he plain text, hvpertext, 
images, or anything else. 

When a user browses the Web. ob¬ 
jects are retrieved in rapid succession 
front often widely dispersed servers. 
For small documents, the limitations 
to the response time stem mainly 
front the number of round trip delays 
across the network necessary before 
the rendition of the object tail he 
started. IFITP is therefore a simple 
request/response protocol. 

HTTP does not only transfer 
HT ML documents. Although HTML 
comprehension is required of \V3 di¬ 
ems. HTTP is used for ret t ier ing 
documents in an unbounded and ex¬ 
tensible set of formats. To achieve 
this, the client sends a (weigltted) list 
of the formats it can handle, and tlie 
server replies with data in any of 
those lormuis that it can produce. 
This allows proprietary formats to he 
used between consenting programs 
in private, without the need for stan¬ 
dardization oft hose loimats. This is 
important Itotlt lot high-end users 
who share data in sophisticated 
forms, tun! also as a hook for formats 
that have yet to he invented. T he 
same negotiation system is used lor 
natural language (Knglish. French, 
for example) where available, its well 
as for compression forms. 

HTTP is an Internet protocol. It is 
similar in its readable, text-based style 
to the File T ransfer (FTP) and Net¬ 
work News (NNTP) Protocols liitn 
have been used to transfer files anti 
news on the Internet for many years. 
Unlike these protocols, however, 
HTTP, is stateless. (That is. it runs 
over a TCP connection that is held 
only for the duration of one opera¬ 
tion.) 'Fhe stateless model is efficient 
when a link from one object may lead 
equally well to an object stored on the 


same server, or to another distant 
server. Tlie purpose of a reference 
such as a URI is that it should always 
refer to tlie "same" (in some sense) 
object. This also makes a stateless 
protocol appropriate, as it ret urns 
results based on the URI but irrele¬ 
vant of any previous operations per- 
lormed by the client. 

T he HTTP request front the diem 
starts with an operation code (known 
as the method, in conformance with 
object-oriented terminology) and the 
URI of the object. The "CKT" 
method used by all browsers is de¬ 
fined to lie identpoteni in that it 
should preserve the state of the Web 
(apart from hilling for the informa¬ 
tion transfer, and statistics). A "PUT" 
method is defined for Iront-end up¬ 
date. and ;t "POST’ method for the 
attachment of a new document to the 
Web, or submission of a lillcd-in form 
or oilier object to some processor. 
Use of PUT and POST is currently 
limited, partly due to scarcity of hy¬ 
pertext editors. The extension to 
other methods is a subject of study. 

When objects are transferred oyer 
the network, information about them 
("metainlorinaiion") is transferred in 
HTTP headers. The set of headers is 
an extension of the Multipurpose 
Internet Mai! Kxtensions (MIMK) set. 
This design decision was taken to 
open the door to integration of hy¬ 
permedia mail, news, and informa¬ 
tion access. Unlike in email, transfer 
in biliary, and transfer in nonstan¬ 
dard lull mutually agreed dootment 
formats is possible. I’ltis allows, lot 
example, servers to indicate links 
from, and titles of. documents (such 
as hit-map images) whose data format 
does not otherwise include such in¬ 
formation. 

T he convention that unrecognized 
HTTP headers and parameters are 
ignored hits made it easy to try new 
ideas on working production servers. 
Phis has allowed the protocol defini¬ 
tion to evolve in a controlled way by 
the incorporation of tested ideas. 

Hypertext Markup Language (HTML) 
Despite the ability of HTTP to negoti¬ 
ate lormats, W3 needed a common 
basic language of interchange lot 
hypertext. HTML is that language, 
and much of tlie fabric of the Web is 
constructed out of it. It was designed 
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Figure i. using the World-Wide Web. Shown here is the authors’ pro¬ 
totype World-Wide Web application for Nextstep machines. The appli¬ 
cation initially displays the users "home" page (top) of personal 
notes and links (top). Clicking on underlined text takes the reader to 
new documents. In this case, the user visited the virtual Library, and. 
in the nigh energy physics department, found a link to CERN. Linked 
to CERN was the "Atlas" collaboration's web including an engineer¬ 
ing drawing (background). To save having to follow the same path 
again, the link menu (shown) allows a new link to be made, for exam pie ’ 
from text typed Into the home page, directly to the Atlas Information. 


to be sulliciently simple so as to be 
easily produced by both people and 
programs, but also to adhere to the 
SGML standard in that a valid 
HTML document, if attached to 
SGML declarations including the 
HTML "DTD," may be parsed by an 
SGML parser. H TM -fc - is a markup 
language that does' 'not have to be 
used with HTTP,-4t-«an be used in 
hypertext email (ir iS'prbposed as a 
format for MIME), news, and any¬ 
where basic hypertext is needed. It 
includes simple structure elements, 
such as several levels of headings, bul¬ 
leted lists, menus and compact lists, 
all of which are useful when present¬ 
ing choices, and in on-line docu¬ 
ments. 

Under development is a much en¬ 
riched version of HTML known has 
HTML+. This includes features for 
more sophisticated on-line documen¬ 
tation. form templates for the entry of 
data by users, tables and mathemati¬ 
cal formulae. Currently many brows¬ 


ers support a subset of the HTML+ 
features in addition to the core 
HTML set. 

HTML is defined to be a language 
of communication, which actually 
flows over the network. There is no 
requirement that files are stored in 
HTML. Servers mav store files in 
other formats, or in variations on 
HTML that include extra informa¬ 
tion of local interest only, and then 
generate HTML, on the lly "’' th each 
request. 


W3 and other Systems 

Two other systems, VVA1S (from 
Thinking Machines Corporation and 
now WAIS, Inc.) and Gopher (front 
the University of Minnesota), share 
W3's client -server architecture and a 
certain amount of its functionality. 
Table 1 indicates some of the differ¬ 
ences. 

The WAIS protocol is influenced 
largely by the 7 . 39.30 protocol de- 
stgned for networking library cata- 
!°S S - It allows a text-based search. 
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Table i. A comparison of three popular network information projects. 

Registered server figures taken April 27,1993 and April 15,1994. WAIS: from Thinking Machines Corporation 
directory, number of distinct hosts. Gopher: from "All the Gophers In the world" register at the University 
of Minnesota. W3: from Geographical registry at CERN. in all cases many more servers exist which are not 
directly registered, so these are a very rough guide with no Indication of quantity or quality of 
Information at each host. 
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and retrieval following a search. In¬ 
dexes to be searched are found by 
searching in a master, index. This 
two-stage search has been demon¬ 
strated to be sufficiently powerful to 
cover the current world of WAIS 
data. There are no navigational tools 
to allow tlie reader to be shown the 
available resources, however, or 
guided through the data: the reader 
is ‘‘parachuted in" to a hopefully rele¬ 
vant spot in tile information world, 
but left without context. 

Gopher provides a lice text search 
mechanism, but principally uses 
menus. A menu is a list of titles, from 
which the user may pick one. While 
gopher space is in fact a web contain¬ 
ing many loops, the menu system 
gives tile user the impression of a 
tree. Tlie Veronica seryeTjajovides a 
master index for goplier space. 

The W3- data model is similar to 
the gopher model, except that menus 
are generalized to hypertext docu¬ 
ments. In both cases, simple file serv¬ 
ers generate the menus or hypertext 
directly from the file structure of a 
server. The W3 hypertext model 
gives the program more power to 
communicate tlie options available to 
the reader, as it can include headings 
and various forms of list structure, for 
example, within the hypertext. 


All three systems allow for the pro¬ 
vision of graphics, sound and video, 
although because the WAIS system 
only has access by text search, text has 
to be associated with graphics files to 
allow them to be lound. 

W3 clients provide access to servers 
of all types, as a single simple inter¬ 
lace to the whole Web is considered 
very important. Unknown to the 
user, several protocols are in use be¬ 
hind the scenes. A common code li- 
brarv "libwww" pm into the public 
domain by CERN has promoted this 
uniformity. Whereas one would not 
wish to see greater proliferation of 
protocols, the existence ol more than 
one protocol probably allows lor the 
most rapid progress during this 
phase in the development ol the field. 
It also allows a certain limited confi¬ 
dence that, if an architecture can en¬ 
compass older systems and allow 
transition io current sysiems. ii will, 
by induction, be able to provide a 
transition to newer and better ideas 
as they are invented. 

Recent W3 Developments 

This article, like others in this issue, 
was derived from material written in 
April 1993 for the INET‘93 confer¬ 
ence. Growth of tlie Web since that 
time has been so great that this sec- 


lion has been compleiely rewritten. 
There are now 329 (May: 1.248/ 
nil her than 62 registered HTTP serv¬ 
ers. and many more cliem programs 
available as then. 

T he initial prototype W3 client was 
a "wvsiwvg" hyperiexi browser/editor 
using NeXTStep. We developed a 
line inode browser, and were encour¬ 
aging the developments of a good 
browser for X workstations. One year 
ago. NCSA's Mosaic W3 browser was 
in wide use on X workstations. Its 
easy iuslallaiioii and use was a major 
reason lor the spread of die Web. 
Today ihere are many browsers avail¬ 
able lor workstations. Macintosh and 
HiM/PC compatible machines, and 
for users with character-based lern.ii- 
nals. Of tlie lintel' category, "Lynx" 
from the University of Kansas pro¬ 
vides full-screen access to the Web for 
users with character terminals or 
emulators running on personal com¬ 
puters. Since new software is appear¬ 
ing frequently, readers are advised to 
check the lists on the Web lor those 
most suited to their needs. 

The availability of browsers and 
the availability of quality information 
have provoked each other. One avail¬ 
able indicator of growth has been 
Merit Inc.’s count of the traffic of var¬ 
ious different protocols across the 
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NSF T3 backbone in the U.S. (see 
Figure 3). 

An indicator of the uptake rate of 
clients is the load on the infi.cem.ch. 
W3 server at CFRN, which provides 
information about the Web itself, 
which more than doubled every 4 
months over tile three years between 
April 1991 and April 1994. 

Information providers have also 
blossomed. Some of these provide 
simple overviews of what is available 
at particular institutes or in particular 
fields. Others use the power of the 
W3 model to provide a virtual world 
of great richness. Examples of servers 
that use hypertext in interesting ways 
are the RAI.-Durliam Particle Data¬ 
base. and the Legal Information In¬ 
stitute's hypertexts of several great 
tomes of American law. Fran/ 
Hoesel's hypertext version of the Vat¬ 
ican's Renaissance Culture exhibit at 
the Library of Congress set an exam¬ 
ple that was followed by many collec¬ 
tions of art, history and other fields. 
The Palo Alto town hall runs a server 
with everything from building regu¬ 
lations to restaurants. As an example 
of the increasing use of the Web for 
commerce, a user-friendly virtual 
clothing store prompts for one's size, 
and points to a virtual store contain¬ 
ing only those clothes that are the 
right si/e and also in stock. 

The Future 

The W3 initiative occupies the meet¬ 
ing point of many fields of technol¬ 
ogy. Users put pressure and effort 
into bringing about the adoption of 
W3 in new areas. Apart from being a 
place of com m umcaflon and learn¬ 
ing, and a new marketplace, the Web 
is a show grouncHbr-pew develop¬ 
ments in information technology. 
Some of the developments that we 
look forward to in the next few years 
include 

• The implementation of a name ser¬ 
vice that will allow documents to be 
referenced by name, independent of 
their location; 

• Hypertext editors allowing nonex¬ 
pert users to make hypertext links to 
organize published information. This 
will bring the goal of computer- 
supported collaboration closer, with 
front-end update, and annotation; 

• More sophisticated document type 
definitions providing for the needs of 



Figure 2 . The World-Wide Web client-server architecture. For pub¬ 
lished information to be universally available, W3 relies on a common 
addressing syntax, a set of common protocols, and negotiation of 
data formats. 



Figure 3 . Traffic in bytes per month across the NSF T3 backbone in 
the u.s. File Transfer Protocol (FTP) was traditionally used to access 
archives of software. FTP uses separate connections for control and 
data flow. WAls arose as an interface to text retrieval systems. Gopher 
protocol with menu-style interfaces, and W3’s HTTP with hypertext 
and multimedia. W3 clients handle many protocols to access all these 
worlds of data as a seamless continuum, but new W3 servers use HTTP 
by preference. Each vertical division represents a tenfold Increase In 
traffic. The horizontal divisions are months. Data: Merit < ftp://ftp. 
rn.erit.edu/statlstics/nsfnet > 
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commercial publisliers of on-line 
material; 

• The development of a common for¬ 
mal for hypertext links from two- and 
three-dimensional images giving 
more exciting interlace possibilities; 

• Integration with concurrent edi¬ 
tors and other real-time features 
such as teleconferencing and virtual 
reality; 

• Easy-to-use servers for low-end 
machines to ease publication of 
information by small groups and 
individuals; 

• Evolution of objects from being 
principally human-readable docu¬ 
ments to contain inuu^machine- 
oricnied semantic inlomBHion, allow¬ 
ing more sophisticate d proc essing: 

• Conventions on the-Internet lor 
charging and commercial use to allow 
direct access to for-prolii services. 

Conclusion 

It is intended that after reading this 
article you will have an idea of what 
W3 is, where it fits in with other sys¬ 
tems in the field, and where it is 
going. There is much more to be 
said, especially about providing 
information, but this is described 


on the Web itself. Also in the "Web 
about the Web" are lists of contrib¬ 
uted research and development work 
and ideas, and pointers to work in 
progress, so that those interested can 
work together. 

The Web does not yet meet its de¬ 
sign goal as being a pool of knowl¬ 
edge that is as easy to update as to 
read. That level of immediacy of 
knowledge sharing wails for easy-to- 
use hypertext editors to be generally 
available on most platforms. Most in¬ 
formation has in fact passed through 
publishers or system managers of one 
sort or another. However, the incred¬ 
ible diversity of information available 
gives great credit to the creativity and 
ingenuity of information providers, 
and points to a very exciting future. 

□ 

Appendix. 

Getting Started 

if you have a vtlOO terminal, you can try 
out a full-screen Interface by telnet to 
ukanalx.cc.ukans.edu and logging In as 
www. Wltn any terminal, you can telnet to 
lnfo.cern.ch for tne simplest Interface. 
These browsers are also available In source 
and in some cases binary form. Details of 
status and coordinates of about 20 differ¬ 


ent browsers are available on tne web- 
just follow a link to World wide Web, and 
select "software available." 

The kernel W3 code la common code li¬ 
brary, and Dasic server and clients) from 
CERN is In tne public domain. (Ail protocols 
and specifications are public domain.) it is 
available Dy anonymous ftp from in- 
fo.cern.ch 

NCSA's "Mosaic" browser for W3 Is avail¬ 
able for x, Mac or PC/Windows by anony¬ 
mous FTP from ftp.ncsa.uluc.edu, cur¬ 
rently wltnout charge for academic users. 
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Message 6: 

From johnm Wed Dec 29 15:42:39 1993 
Date: Wed, 29 Dec 1993 15:42:39 -0800 
From: John Markoff <johnm> 

To: kmh 

Subject: for you... 

X-Newsreader: NN version 6.5.0 #1 (NOV) 


>Xref: well alt.amateur-comp:2083 alt.culture.internet:1239 
soc.history:20039 comp.misc:6607 alt.folklore.computers:34691 alt.politi 
cs.datahighway: 1064 alt.cyberspace:3566 
>Path: 

well !nigel.msen.comIspool.mu.edu Isol.ctr.columbia.edu lnews.cs.Columbia. 

edulnews.cs.columbia.edu !news-not-for-mail 

>From: hauben@news.cs.columbia.edu (Michael Hauben) 

>Newsgroups: alt.amateur- 

comp,alt.culture.internet,soc.history,comp.misc,alt.folklore.computers,alt.p 
olitics. datahighway, alt. cy bersp 
ace,ny.general 

>Subject: Draft History of early ARPANET Part 1/3 
>Date: 28 Dec 1993 23:26:30 -0500 

Organization: Columbia University Department of Computer Science 
>Lines: 355 

>Mess age-ID: <2fr0tm$ph 8 @ tune. cs. columbi a.edu> 

>Reply-To: hauben@cs.columbia.edu 
>NNTP-Posting-Host: tune.cs.columbia.edu 

The following is a first draft on some research I have done on 
the early history of the ARPANET and the Network Working Group. 

Any comments or criticism would be helpful. And when I finish 
the paper, I int4end to post it back to the Net. Thanks. 

Behind die Net - The untold history of the ARPANET ' 

Or - The "Open" History of the ARPANET/Internet 
(subject to revision - First Draft) 

By Michael Hauben 
hauben @ columbia.edu 


The global Internet's progenitor was the Advanced 
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Research Projects Agency Network (ARPANET) of the U.S. Department 
of Defense. This is an important fact to remember, because the 
support and style of management by ARPA was crucial to the success 
of ARPANET. As the Internet develops and the struggle over the 
role the Internet plays unfolds, it will be important to remember 
how the network developed and the culture that it was connected 
with.(As a facilitator of communication, the culture of the Net 
is an important feature to acknowledge.) The ARPANET Completion 
Report, as published jointly by BBN of Cambridge, Mass., and ARPA 
concludes by stating: 

"...it is somewhat fitting to end on the note that the 
ARPANET program has had a strong and direct feedback into the 
support and strength of computer science, from which the network 
itself sprung." (Chapter III, pg.132, Section 2.3.4) 

In order to understand the wonder that the Internet, and 
various parts of the Net, represent, we need to understand why 
the ARPANET Completion report ends with the suggestion that the 
ARPANET is fundamentally connected to and born of computer 
science. [Make more of this paragraph] 

PART I: The history of ARPA leading up to the ARPANET 

A climate of pure research surrounded the entire history 
of the ARPANET. The Advanced Research Projects Agency was formed 
with an emphasis towards research, and thus was not oriented only 
to a military product. The formation of this agency was part of 
the U.S. reaction to the then Soviet Union's launch of Sputnik 
in 1957. (ARPA draft, ID-6). ARPA was assigned to research how 
to utilize their investment in computers via Command and Control 
Research(CCR). Dr. J.C.R. Licklider was chosen to head this 
effort. LickEdp: came to ARPA from Bolt, Beranek and Newman, 

(BBN) in Cambridge, MA in October 1962. (ARPA draft,' HI-6) 

From Licklider's arrival, the department's contracts were 
shifted from independent corporations towards "the best academic 
computer centers" (ARPA draft, III-7). The then current computing 
mode was via batch processing (you know, input via stacks of 
punched cards, output: results, or lack of them, made known one 
or more days later.). Licklider saw improvements could be made in 
CCR only via work on advancing the current state of computing 
technology. He particularly wanted to move forward into the age 
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of interactive computing, and the current contractors were not 
moving in that direction. In an Interview, Licklider told the 
interviewee that SDC "was based on batch processing, and while I 
was interested in a new way of doing things, they [SDC] were 
studying how to make improvements in the ways things were done 
already." (An Interview with J.C.R. Licklider conducted by 
William Aspray and Arthur Norberg on October 28, 1988 Cambridge, 
Mass. CBI Univ of Minn., Madison) The office "developed into a 
far-reaching basic research program in advanced technology." 

(ARPA draft III-7) Licklider's Office was renamed Information 
Processing Techniques (IPT or IPTO) to reflect that change. 

The Completion report states that "Prophetically, 

Licklider nicknamed the group of computer specialists he gathered 
the 'Intergalactic Network'." ARPA draft, III-7) Before work on 
the ARPANET began, the very idea of the network was planted by 
the creation of the Information Processing Techniques Office of 
ARPA. Robert Taylor, Licklider's successor at the IPTO, remembers 
Lick's interest in interconnecting communities: 

"Lick was among the first to perceive the spirit of community 
created among the users of the first time-sharing systems... 

In pointing out the community phenomena created, in part, 
by the sharing of resources in one timesharing system, Lick 
made it easy to think about interconnecting the 
communities, the interconnection of interactive, on-line 
communities of people, ..." (ARPA draft, III-21) 

The "spirit of community" was related to Lick's interest 
in having computers help people communicate with other people 
(Licklider, Licklider, and Robert Taylor, "The Computer as a 
Communication Device") Licklider's vision of an "intergalactic 
network" connecting people represented an important conceptional 
shift in com put er science. This vision was also an important 
beginning to the'ARPANET. After the ARPANET was up and running, 
the computer scientists using it realized that assisting human 
communication was the most fundamental advance that the ARPANET 
made possible. (Cite Larry Roberts) 

As early as 1963, a common question asked of the IPTO 
directors by the ARPA directors about IPTO projects was "Why 
don't we rely on the computer industry to do that?", or 
ocassionally more strongly, "We should not support that effort 
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because ABC (read, "computer industry") will do it - if it's 
worth doing!" (ARPA draft, III-23) This question leads to an 
important point - this ARPA research was different from what the 
computer industry had in mind to do - or was likely to undertake. 
Since Licklider's creation of the IPTO, the work supported by 
ARPA/IPTO continued his explicit emphasis on communications. The 
Completion Report explains, 

"The ARPA theme is that the promise offered by the computer as a 
communication medium between people, dwarfs into relative 
insignificance the historical beginnings of the computer as an 
arithmetic engine." (ARPA draft, III-24) 

The Completion Report goes on to differentiate ARPA from the 
computer industry: 

"The computer industry, in the main, still thinks of the computer 
as an arithmetic engine. Their heritage is reflected even in 
current designs of their communication systems.' They have an 
economic and psychological commitment to the arithmetic engine 
model, and it can die only slowly..." (ARPA draft, III-24) 

The Completion Report further analyzes this problem by tracing 
it back to the nation's institutions: 

"...furthermore, it is a view that is still reinforced by most of 
the nation's computer science programs. Even universities, or at 
least parts of them, are held in the grasp of the arithmetic 
engine concept...." (ARPA draft, III-24) 

Since Licklider's creation of the IPTO, the work supported by 
ARPA/IPTO continued the explicit communications emphasis. Thus 
history has, witnessed the research and development which had led 
to the conc rete existence of first the ARPANET, and later the 
Internet. Without the commitment that existed via this support, 
such a development might never have happened. One of ARPA's 
criterion for supporting research was such that it had to be of 
such a level to offer an order of magnitude of development. As 
most research and development is not immediately profitable, 
there has to be some kind of organization which helps to set 
higher goals than just in developing what will be immediately 
profitable. What is really strange is that computer networking is 
an immensely profitable field right now - only it is 25 years 
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later. 

Others have understood the communications promise of 
computers. For example, in RFC 1336, David Clark is quoted, 

"It is not proper to think of networks as connecting 
computers. Rather, they connect people using computers to 
mediate. The great success of the internet is not technical, but 
in human impact. Electronic mail may not be a wonderful advance 
in Computer Science, but it is a whole new way for people to 
communicate. The continued growth of the Internet is a technical 
challenge to all of us, but we must never loose sight of where we 
came from, the great change we have worked on the larger computer 
community, and the great potential we have for future change." 

Various research outside of ARPA had been done by Paul 
Baron, Thomas Marill and others. [This history is covered well in 
the article "From ARPANET to USENET" by Ronda Hauben..ref] This 
led Lawrence Roberts and other IPTO staff to formally introduce 
the topic of networking computers of differing types 
(incompatible hardware and software) together in order to share 
resources to the early 1967 meeting of ARPA's Primary 
Investigators (PI). 

In the spring of 1967 at the University of Michigan, ARPA 
held its yearly meeting of the "principle investigators" from 
each of its university and other contractors. (ARPA draft, 

ID-25) Results from the previous year's research was summarized 
and future research was discussed, either introduced by ARPA or 
the various researchers present at the meetings. Networking was 
one of the topics brought up at this meeting. (ARPA draft, ID-25) 

The Completion Report continues the story: 

"At the meeting it was agreed that work could begin on the 
conventions to be used for exchanging messages between any pair of 
computers in the proposed network, and also on consideration of 
the kinds of communications lines and data sets to be used. In 
particular, it was decided that the inter-host communication 
'protocol' would include conventions for character and block 
transmission, error checking and retransmission, and computer and 
user identification. Frank Westervelt, then of the University of 
Michigan, was picked to write a position paper on these areas of 
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communication, an ad hoc 'Communication Group' was selected 
from among the institutions represented, and a meeting of the 
group scheduled." (ARPA draft, III-26) 

In order to develop this network of varied computers, two 
main problems had to be solved: 

" 1. To construct a 'subnetwork' consisting of telephone circuits 
and switching nodes whose reliability, delay characteristics, 
capacity, and cost would facilitate resource sharing among 
computers on the network. 

2. To understand , design, and implement the protocols and 
procedures within the operating systems of each connected 
computer, in order to allow the use of the new subnetwork by the 
computers in sharing resources." (ARPA not draft, D-8) 

After one draft and additional work on this communications 
position paper report, a two-day meeting was scheduled in early 
October 1967 by ARPA to "discuss the protocol paper and 
specifications for the Interface Message Processor (IMP)." The IMP 
was the decided upon method of connecting the participants 
computers (hosts) to each other via phone lines. This 
standardized the network which the hosts connected to. Now, only 
the connection of the hosts to the network would depend on vendor 
type, etc. ARPA had picked 19 possible participants in what was 
now known as the "ARPA Network", rather than the previously vague 
descriptions. 

After the time of the 1967 PI Meeting, various computer 
scientists who were ARPA contractors were busy thinking about 
various aspects which would be relevant to the planning and 
development:!#: the ARPANET. Part of that work was a document 
outlining a Beginning design for the IMP network. This - ' 
specification would lead to the ability to a put out a 
competitive procurement for the design of the IMP subnetwork. 

"At the end of 1967 ARPA initiated a small contract with the Stanford 
Research Institute for the development of specifications for the 
necessary communications system. Elmer Shapiro was to be the key 
person on this study. Published in the final version in December 
of 1968 was a 71-page SRI report entitled "A Study of Computer 
Network Design Parameters", an early version in early 1968 served 
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as the first draft of the IMP specification...In February or March 
a memo written by Shapiro and revised by Kleinrock entitled 
"Functional Description of the IMP" was circulated. After the 
first draft by Shapiro, it is believed that Glenn Culler wrote a 
second draft, and Robert and Wessler of ARPA wrote the final 
version of the IMP specification. In any case, by the first of 
March, 1968, IPT was able to report to the Director of ARPA that 
specifications for the IMP were essentially complete, and that 
they would be discussed at the upcoming PI meeting with the goal 
of issuing a Request for Quotation shortly thereafter. The 
network was discussed at the PI meeting and by June 1968, the 
ARPANET procurement officially started." (ARPA draft, III-32) 

ARPA's Program Plan for the ARPANET was titled "Resource 
Sharing Computer Networks". It was submitted June 3, 1968, and 
approved by the Director June 21, 1968. 

The Completion Report explains that the Program Plan was, 

"an interesting document. The stated objectives of the program 
were to develop experience in interconnection computers and to 
improve and increase computer research productivity through 
resource sharing. Technical needs in scientific and military 
environments were cited as justification for the program 
objectives. Relevant prior work was described. It was noted that 
the computer research centers supported or partially supported by 
IPT provided a unique testbed for computer networking 
experiments, as well as providing immediate benefits to the 
centers and valuable research results to the military. The 
network planning that had gone on was described, the need for a 
network information center was noted, and the network design was 
sketched. A five year schedule for network procurement, 
construction, operation, and transfer out of ARPA was presented. 

(It was noteworthy that IPT had initially had in mind eventual 
transfer of ]hefoperational network to a common carrier.)'Finally 
a several-millk>n : dollar, several-year budget was stated." (ARPA 
draft, III-35) 

[TRANSITION NEEDED] 

"The Defense Supply Service - Washington (DSS-W) agreed to 
be a procurement agent for ARPA. At the end of July the Request 
for Quotation for network IMPs was mailed to 140 potential 
bidders who had expressed interest in receiving it. Approximately 
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100 people from 51 companies attended a subsequent bidders' 
conference [footnote about common carriers] Twelve proposals were 
actually received by DSS_W comprising 6.6 edge-feet of paper and 
presenting an awesome evaluation task for IPT, which more 
normally awards contracts on a sole source basis. Attempting to 
evaluate the proposals "strictly by the book", an ARPA-appointed 
evaluation committee retired to Monterey, California, to carry 
out their task. ARPA was pleasantly surprised that several of the 
respondents believed that they could construct a network which 
performed as much as a factor of five better than the delay 
constraint given in the RFQ..." (ARPA draft, III-35) 

ARPA developed a program plan, which developed into a set 
of specifications. These specifications were connected to a 
competitive Request for Quotation to find an organization which 
would design and build the subnetwork between the IMPs. 

BBN won the contract to develop the IMP-to-IMP 
subnetwork. However the second technical problem still remained 
to be solved. The protocol to allow the hosts to communicate with 
each other over the subnetwork had to be developed. This work was 
left "for host sites to work out among themselves." (ARPA draft, 
ffl-67) This meant that both the hardware and software necessary 
to connect the hosts to the IMP subnetwork had to be developed. 

ARPA assigned this duty to the initial designated ARPANET sites. 

As each site had a different type of computer to connect, they 
individually were the best informed designers for their personal 
setups. In addition the sites needed to develop the hardware and 
software necessary to utilize the other hosts on the network. 

(ARPA draft, IE-39) ARPA's assigning of responsibilities makes 
the academic computer science community become an active part of 
the ARPANET development team. (Interview with Alex McKenize, Nov, 
1 1993) 

Steve Crocker associates the placement of the initial ' 

ARPANET sites at research institutions to the fact that the 
ARPANET was ground-breaking research. He wrote in a message 
responding to my questions on the COM-PRIV mailing list: 

"During the initial development of the Arpanet, there was simply a 
limit as to how far ahead anyone could see and manage. The IMPs were 
placed in cooperative ARPA R&D sites with the hope that these research 
sites would figure out how to exploit this new communication 
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medium." (Crocker, 1993A) 

The first sites of the ARPANET were picked to provide 
either network support services or unique resources. They were 
also picked as deemed technically able of developing the 
protocols necessary to make communications between the varied 
computers connected possible. The key services the first four 
sites provided were 

"UCLA - Network Measurement Center 
SRI - Network Information Center 
UCSB - Culler-Fried interactive mathematics 
UTAH - graphics (hidden line removal)" (Cerf, Vinton 1993) 

Steve Crocker also recounts that the reason for selecting these 
particular four sites was because they were "existing ARPA 
computer science research contractors." This was important 
because "the research community could be counted on to take some 
initiative." (RFC 1000, pg 1) 

The very first site to receive an IMP was UCLA. Professor 
Leonard Kleinrock of UCLA was involved with much of the early 
development of the ARPANET. His work consisted of understanding 
queueing theory and as such was one of the first computer 
scientists working on the ARPANET who was dealing with how to 
measure what was happening as the network would function. This 
made it natural to make sure that UCLA received the first node as 
it would be important to initiate the network from the site which 
would measure the networks activity. In order for the statistics 
to be correct and for analysis purposes - the first site had to 
be the measurement site. Sure enough UCLA was assigned to be the 
Network Measurement Center (NMC). [FOOTNOTE 1] 
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Date: Wed, 29 Dec 1993 15:43:08 -0800 
From: John Markoff <johnm> 

To: kmh 
Subject: part II 

X-Newsreader: NN version 6.5.0 #1 (NOV) 


>Xref: well alt.amateur-comp:2084 alt.culture.internet:1240 
soc.history:20041 comp.misc:6608 alt.folklore.computers:34692 alt.politi 
cs.datahighway: 1065 alt.cyberspace:3567 
>Path: 

well!nigel.msen.comlspool.mu.edu !sol.ctr.columbia.edu lnews.cs.Columbia. 

edu lnews.es.columbia.edulnews-not-for-mail 

>From: hauben@news.cs.columbia.edu (Michael Hauben) 

>Newsgroups: alt.amateur- 

comp,alt.culture. internet, soc.history,comp.misc,alt.folklore.computers,alt.p 
olitics. datahigh way,alt. cybersp 
ace, ny. general 

>Subject: Draft History of early ARPANET Part 2/3 
>Date: 28 Dec 1993 23:31:14 -0500 

Organization: Columbia University Department of Computer Science 
>Lines: 351 

>Message-ID: <2frl6i$plr@tune.cs.columbia.edu> 

>Reply-To: hauben@ cs.columbia.edu 
>NNTP-Posting-Host: tune.cs.columbia.edu 

Part II. The Network Working Group 

Once the initial sites were picked, representatives from 
each site gathered together to start talking about solving the 
technical problem of getting the hosts to communicate via 
protocols. The ARPA Completion report tells us about this 
beginnings .".T. . 

"To provide the hosts with a little impetus to work on 
the host-to-host problems. ARPA assigned Elmer Shapiro of SRI "to 
make something happen", a typically vague ARPA assignment. 

Shapiro called a meeting in the summer of 1968 which was attended 
by programmers from several of the first hosts to be connected to 
the network. Individuals who were present have said that it was 
clear from the meeting at that time, no one had even any clear 
notions of what the fundamental host-to-host issues might be." 

(AC Draft IE-67 1.4.1.7) 
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Again, we see that this group, which came to be know as 
the Network Working Group (NWG), was exploring new territory. The 
first meeting took place several months before the first IMP was 
put together and they had to think from a blank slate. Throughout 
the existing recollections of the important developments the NWG 
produced, (especially RFC 1000) the reader is reminded that the 
thinking involved was totally original and thus 
thought-provoking. Steve Crocker remembers in the RFC Reference 
Guide (RFC 1000) that the first meeting was chaired by Elmer 
Shapiro, who initiated the conversation with a list of questions. 

(Crocker, 1993b) Also present were Steve Carr from University of 
Utah, Stephen Crocker from UCLA, Jeff Rulifson from SRI, and Ron 
Stoughton from UCSB. These attendees are the programmers referred 
to in the ARPANET Completion Report. 

In the words of Steve Crocker, this was a seminal meeting. 

The attendees could only be but theoretical, as none of 
the lowest levels of communication had been developed yet. They 
needed a transport layer or low-level communications platform to 
be able to build upon. BBN did not deliver the first IMP until 
August 30, 1969. It was important to meet beforehand, as the NWG 
"imagined all sorts of possibilities." (RfclOOO) Only once their thought 
processes started could this working group actually develop anything. 
These fresh thoughts from fresh minds help to incubate new ideas. 

The ARPANET Completion Report properly acknowledges what this 
early group helped accomplished: " Their early thinking was at a 
very high level." (ARPA draft, III-67) A concrete decision of 
the first meeting was to continue holding meetings similar to the 
first one. This wound up setting the precedent of a holding exchange 
meetings at each of the sites. 

SteveUfocker, describing the problems facing these- . 
networkinglp^neers, writes: 

"With no specific service definition in place for what the IMPs 
were providing to the hosts, there wasn't any clear idea of what 
work the hosts had to do. Only later did we articulate the 
notion of building a layered set of protocols with general 
transport services on the bottom and multiple application- 
specific protocols on the top. More precisely, we understood 
quite early that we wanted quite a bit of generality, but we 
didn't have a clear idea how to achieve it. We struggled between 
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a grand design and getting something working quickly."(Crocker, 1993c) 

The initial protocol development lead to DEL (Decode- 
Encode-Language) and NIL (Network Interchange Language). These 
languages were ahead of their time. The basic purpose was to form 
an on-the-fly description that would tell the receiving end how 
to understand the information that would be sent. However, these 
first set of meetings were extremely abstract as neither ARPA nor 
the universities had deemed any official charter. The lack of a 
charter allowed the group to think broadly and openly however. 

BBN did submit details as to the host-IMP interface 
specifications from the IMP side. This information provided the 
group some definite starting points to build from. Soon after BBN 
provided more information, on Valentine's Day, 1969, members of 
the NWG, members of BBN and members of the Network Analysis 
Corporation (NAC) met for the first time. [The NAC was contracted 
by ARPA to "specify the topological design of the ARPANET and to 
analyze its cost, performance, and reliability characteristics. 

(ARPA not draft, III-30)] As all the parties had different 
priorities on mind, the meeting was a difficult one. BBN was 
interested in the lowest level of making a reliable connection. 

The programmers from the host sites were interested in getting 
the hosts to communicate with each either via various higher 
level programs. And BBN also did not turn out to be the "experts 
from the East" that Steve Crocker wrote the members of the NWG 
expected. He continues by writing in RFC 1000 that they constantly 
thought that "a professional crew would show up eventually to take 
over the problems we were dealing with." 

A step of incredible importance and openness occurred as a 
result from a "particularly delightful" meeting that took place a 
month latejriirfJtah. (RFC 1000) The participants decided it. was 
time to sta rt rec ording their meetings in a consistent fashion.- 
What resultechwas a set of informal notes titled "Request for 
Comments." Steve Crocker writes about their formation: 

"I remember having great fear that we would offend whomever the 
official protocol designers were, and I spent a sleepless night 
composing humble words for our notes. The basic ground rules were 
that anyone could say anything and that nothing was official. And to 
emphasize the point, I labeled the notes "Request for Comments." I 
never dreamed these notes would distributed through the very medium 
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we were discussing in these notes. Talk about Sorcerer's Apprentice!" 

(Crocker, RFC 1000, pg 3, 1987) 

Crocker replaced Shapiro as the Chairman of the NWG after 
the initial meeting. He describes how they wrestled with creation 
of the host-host protocols: 

"Over the spring and summer of 1969 we grappled with the detailed 
problems of protocol design. Although we had a vision of the vast 
potential for intercomputer communication, designing usable protocols 
was another matter. A custom hardware interface and custom intrusion 
into the operating system was going to be required for anything we 
designed, and we anticipated serious difficulty at each of die sites. 

We looked for existing abstractions to use. It would have been 
convenient if we could have made the network simply look like a tape 
drive to each host, but we knew that wouldn't do." 

(Crocker, RFC 1000, pg. 3) 

The first two IMPs were delivered to UCLA (number 1) and 
SRI (Number 2). [Footnote 2] Once two IMPs existed, the NWG had 
to implement a working protocol. This first set of host protocols 
included a remote login for interactive use (telnet), and a way 
to copy files between remote hosts (FTP). Crocker writes: 

"In particular, only asymmetric, user-server relationships 

were supported. In December 1969, we met with Larry Roberts in Utah, 

[and he] made it abundantly clear that our first step was not 

big enough, and we went back to the drawing board. Over the 

next few months we designed a symmetric host-host protocol, 

and we defined an abstract implementation of the protocol 

known as the Network Control Program. ("NCP" later came to be 

used as the name for the protocol, but it originally meant the 

program^OTthin the operating system that managed connections. 

The protdqpl'itself was known blandly only as the host-host 
protocol.) - Along with the basic host-host protocol, we also 
envisioned a hierarchy of protocols, with Telnet, FTP and some 
splinter protocols as the first examples. If we had only consulted 
the ancient mystics, we would have seen immediately that seven layers 
were required." (RFC 1000, pg 4) 

After Robert's guidance, the Network Working Group went 
forward in developing the protocols necessary to make the network 
viable. The group swelled in attendance as more and more sites 
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connected to the ARPANET. The group became large enough (around 
100 people) that one meeting was held in conjunction with the 
1971 Spring Joint Computer Conference in Atlantic City. A major 
test of the NWG's work came in October 1971, when a meeting was 
held at MIT. Crocker continues the story, 

"[A] major protocol "fly-off" - Representatives from each site were on 
hand, and everyone tried to log in to everyone else's site. With the 
exception of one site that was completely down, the matrix was almost 
completely filled in, and we had reached a major milestone in 
connectivity." (Crocker, RFC 1000, pg. 4) 

The NCP was created as what was called the "host to host 
protocol." Explaining why this was important, the authors of the 
ARP A draft write: 

"The problem is to design a host protocol which is sufficiently 
powerful for the kinds of communication that will occur and yet 
can be implemented in all of the various different host computer 
systems. The initial approach taken involved an entity called a 
"Network Control Program" which would typically reside in the 
executive of a host, such that processes within a host would 
communicate with the network through this Network Control 
Program. The primary function of the NCP is to establish 
connections, break connections, switch connections, and control 
flow. A layered approach was taken such that more complex 
procedures (such as File Transfer Procedures) were built on top 
of similar procedures in the host Network Control Program." 

(Arpa draft, 11-24) 

As the ARPANET grew, the number of Users bypassed the 
number of developers. This signaled the success of these 
networking jpisneers. Steve Crocker appointed Alex McKenize and 
Jon Postel to.replace him as Chairmen of the Network Working 
Group. The Completion Report details how this role changed: 

"McKenzie and Postel interpreted their task to be one of 
codification and coordination primarily, and after a few more 
spurts of activity the protocol definition process settled for the 
most part into a status of a maintenance effort."(ARPA draft,ID-69) 

ARPA (Advanced Research Projects Agency) was a management 
body which lent funding to academic computer scientists. ARPA's 
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smart management sense paved the way for these scientists to 
create the ARPANET. BBN helped via developing the packet 
switching techniques most suitable to passing a wide variety of 
information. However, the most important development was that of 
the "Request for Comments" documentation. 

3. About RFC's as "Open" Documentation 

The openness initiated from the very first meeting of the 
Network Working Group continued on in a more informal formalized 
manner in the Request For Comments. As meeting notes, the RFCs 
were meant to keep members updated on the status of several 
things. They were also meant to gather responses from people. 

The Documentation Conventions RFC (RFC 3) documents the "rules" 
governing the production of these notes. Topping the page were 
the open distribution rules: 

"Documentation of the NWG's effort is through notes such as this. 

Notes may be produced at any site by anybody and included in this 
series." 

The guide goes on to describe the rules concerning the contents 
of the RFCs: 

"The content of a NWG note may be any thought, suggestion, etc. related 
to 

the HOST software or other aspect of the network. Notes are encouraged 
to 

be timely rather than polished. Philosophical positions without examples 
or other specifics, specific suggestions or implementation techniques 
without introductory or background explication, and explicit questions 
without any attempted answers are all acceptable. The minimum length for 
a NWG noleriSKme sentence." 

The RFC continues to explain the philosophy behind the 
unprecedented amount of openness represented: 

"These standards (or lack of them) are stated explicitly for two 
reasons. First, there is a tendency to view a written statement 
as ipso facto authoritative, and we hope to promote the exchange 
and discussion of considerably less than authoritative ideas. 

Second, there is a natural hesitancy to publish something 
unpolished, and we hope to ease this inhibition." (Crocker, RFC 3 
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- 1969) [The entire RFC is reproduced in the Appendix B.] 

This openness led to the exchange of information. These open 
principles are what made the development of the Net possible. 

Statements like the ones contained in RFC 3 are very 
progressive in their openness. Late 1960's was a time awash in 
popular protest for freedom of speech and demanding more of a say 
of how the country is run. The openness contained in trying to 
develop new technologies fits well with the cry for more 
democracy which students demanded throughout the country and the 
world. What is amazing is that the collaboration of the NWG 
(mostly graduate students) and ARPA (a component of the 
military), seems to be contrary to the normal atmosphere of the 
times. Robert Braden of the Internet Activities Board reflects on 
this collaboration: 

"For me, participation in the development of the ARPAnet and 
the Internet protocols has been very exciting. One important 
reason it worked, I believe, is that there were a lot of very 
bright people all working more or less in the same direction, 
led by some very wise people in the funding agency. The 
result was to create a community of network researchers who 
believed strongly that collaboration is more powerful than 
competition among researchers. I don't think any other model 
would have gotten us where we are today." (RFC 1336) 

What is even more important is the work of these computer 
scientists founded what has lead to the most amazing and 
democratic body (i.e.: The Net and the culture attached to it) to 
emerge in long time. The community that has developed and the 
tools which accompany it form an important democratic force. [See 
footnote 3|3 ; 

The idearof calling these notes a "Request for Comment" 
is a fascinating tradition. It predates the Usenet Post, which in 
a fashion could be called a "request for comment" as it is the 
presentation of a particular person's ideas, questions or 
comments, to the general public (of those who read that 
newsgroup) for comments, criticism or suggestion, or just plain to 
further the readers' knowledge. Other Early RFCs echo this 
reality. There exist RFCs which are in response to previous RFCs. 
Following are some examples, more are contained in the appendix. 
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65 Walden, D. Comments on Host/Host Protocol document #1 
1 Crocker, S. Host software 1969 April 7 

39 Harslem, E.; Heafner, J. Comments on protocol re: NWG/RFC #36 
38 Wolfe, S. Comments on network protocol from NWG/RFC #36 
36 Crocker, S. Protocol notes 1970 March 16 

47 Crowther, W. BBN's comments on NWG/RFC #33 1970 April 20 
33 Crocker, S. New Host-Host Protocol 1970 February 12 

Part IV: Conclusion 

The Network Working Group's development of open technical 
documentation - the RFC - was a necessary step to technical 
advancement. Steve Crocker explains the importance of openness 
in a developmental situation: 

"The environment we were operating in was one of open research. 

The only payoff available was to have good work recognized and 
used. Software was generally considered free. Openness wasn't 
an option; it just was." (Crocker, 1993c) 

The NWG's work was important (THE?) to the development of 
the ARPANET. Their work paved the way for the development of 
TCP/IP, when more capacity was needed and other problems arose. 

I would call the RFC one of the Heralding Achievements of 
the NWG. It represents the forward looking view which these 
people had and it proved to succeed. The principles which embody 
RFC 3 foreshadowed the success of TCP/IP from NCP's influence. 

Both TCP/IP and NCP were developed in the field. A version of the 
protocols woufel be released for experimentation and use. Also all 
specificafionVwere available free and easily available for ' 
people to examine and make comments about. Only through this 
early release were the problems and kinks found and worked out in 
a timely manner. This bottom-up approach is substantially 
different than the top-down approach which other protocol suites 
have been developed under. The top-down idea comes from figuring 
everything out as a standard on paper, or behind closed doors and 
then releasing it to be used. The bottom-up (and free 
accessibility of protocol documentation and specifications) model 
allows for a wide-range of people and experiences to join in and 
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perfect the protocol and make it the best possible. (Check email 
in TCPIP.MAIL file to provide quotes.) 

In summing up the achievements of the process that 
developed the ARPANET, the ARPANET Completion Report draft 
explains: 

"The ARPANET development was an extremely intense activity in 
which contributions were made by many of the best computer 
scientists in the United States. Thus, almost all of the "major 
technical problems" already mentioned received continuing 
attention and the detailed approach to those problems changed" [11-24] 

The computer scientists and others involved were encouraged in 
their work by the ARPA philosophy of gathering the best computer 
scientists working in the field and supporting them: 

"IPT usually does little day-to-day management of its contractors. 
Especially with its research contracts, IPT would not be 
producing faster results with such management as research must 
progress at its own pace. IPT has generally adopted a mode of 
management which entails finding highly motivated, highly skilled 
contractors, giving them a task, and allowing them to proceed by 
themselves." (III-47) 

The result, explained by the Completion Report was a new way of 
looking at computers as communications devices rather than as 
arithmetic devices. Yet many computer science department still do not 
understand this significance today. 

I Michael Hauben CC '95 I E-mail me for sample copies of I 
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& 

Message 8: 

From johnm Wed Dec 29 15:43:34 1993 
Date: Wed, 29 Dec 1993 15:43:33 -0800 
From: John Markoff <johnm> 

To: kmh 
Subject: Part III 
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X-Newsreader: NN version 6.5.0 #1 (NOV) 


>Xref: well alt.amateur-comp:2085 alt.culture.internet: 1241 
soc.history:20042 comp.misc:6609 alt.folklore.computers:34693 alt.politi 
cs.datahighway: 1066 alt.cyberspace:3568 
>Path: 

well lnigel.msen.comlspool.mu.edu lsol.ctr.columbia.edu lnews.cs.Columbia. 

edulnews.cs.columbia.edu !news-not-for-mail 

>From: hauben@news.cs.columbia.edu (Michael Hauben) 

>Newsgroups: alt.amateur- 

comp,alt.culture.internet,soc.history,comp.misc,alt.folklore.computers,alt.p 

olitics.datahighway,alt.cybersp 

ace,ny. general 

>Subject: Draft History of early ARPANET Part 3/3 
>Date: 28 Dec 1993 23:35:22 -0500 

>Organization: Columbia University Department of Computer Science 
>Lines: 264 

>Message-ID: <2frlea$pqc@tune.cs.columbia.edu> 

>Reply-To: hauben@cs.columbia.edu 
>NNTP-Posting-Host: tune.cs.columbia.edu 


END - NOTES 


1. These quotes show some of the perspective chosen to pick the 
initial ARPANET sites. 

IE - 689 "CCN's [The Campus Computing Network of UCLA] chance to 
obtain a connection to the ARPANET was a result of the presence 
at UCLA of Professor L. Kleinrock and his students, including S. 
Crocker, J. Postel, and V. Cerf. This group was not only involved 
in the origyjafedesign of the network and the Host protocols., but 
also was to ope rate the Network Measurement Center (NMC). For 
these reasonsThe first delivered IMP was installed at UCLA, and 
ARPA was thus able to easily offer CCN the opportunity for 
connection." 

pg 11-16 

" In a somewhat less structured way, the research groups 
receiving ARPA IPTO support were then encouraged to begin 
considering the design and implementation of protocols and 
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procedures and, in turn, computer program modifications, in the 
various host computers in order to use the subnetwork. Several 
specific responsibilities were arranged: UCLA was specifically 
asked to take on the task of a "Network Measurement Center" with 
the objective of studying the performance of the network as it 
was built, grown, and modified; SRI was specifically asked to 
take on the task of a "Network Information Center" with the 
objective of collecting information about the network, about host 
resources, and at the same time generating computer based tools 
for storing and accessing that collected information. Beyond 
these two specific contracts, some rather ad hoc mechanisms were 
pursued to reach agreement between the various research 
contractors about the appropriate "host protocols" for 
intercommunicating over the subnetwork. The "Network Working 
Group" of interested individuals from the various host sites was 
rather informally encouraged by ARPA. After a time, this Network 
Working Group became the forum for, and eventually a 
semi-official approval authority for, the discussion of and " 

III - 60 1.4.1.5 The Network Information Center 

The accessibility of distributed resources carries with it the 
need for an information service (either centralized or 
distributed) that enables users to learn about those resources. 

This was recognized at the PI [ed. Primary Instigators] meeting 
in Michigan in the spring of 1967. At the time, Doug Engelbart 
and his group at the Stanford Research Institute were already 
involved in research and development to provide a computer-based 
facility to augment human interaction. Thus, it was decided that 
Stanford Research Institute would be a suitable place for a 
"Network Information Center" (NIC) to be established for the 
ARPANET. With the beginning of implementation of the network in 
1969, conslruetion also began on the NIC at SRI." 


2. RFC 1000 reports on the process of the installation of the 
first IMP. 

"[T]ime was pressing: The first IMP was due to be 
delivered to UCLA September 1, 1969, and the rest were scheduled 
at monthly intervals. 

At UCLA we scrambled to build a host-IMP interface. SDS, the builder 
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of the Sigma 7, wanted many months and many dollars to do the job. 
Mike Wingfield, another grad student at UCLA, stepped in and offered 
to get interface built in six weeks for a few thousand dollars. He 
had a gorgeous, fully instrumented interface working in five and one 
half weeks. I was in charge of the software, and we were naturally 
running a bit late. September 1 was Labor Day, so I knew I had a 
couple of extra days to debug the software. Moreover, I had heard 
BBN was having some timing troubles with the software, so I had some 
hope they'd miss the ship date. And I figured that first some 
Honeywell people would install the hardware — IMPs were built out of 
Honeywell 516s in those days — and then BBN people would come in a 
few days later to shake down the software. An easy couple of weeks 
of grace. 

BBN fixed their timing trouble, air shipped the IMP, and it arrived 
on our loading dock on Saturday, August 30. They arrived with the 
IMP, wheeled it into our computer room, plugged it in and the 
software restarted from where it had been when the plug was pulled in 
Cambridge. Still Saturday, August 30. Panic time at UCLA. 

The second IMP was delivered to SRI at the beginning of October, and 
ARPA's interest was intense. Larry Roberts and Barry Wessler came by 
for a visit on November 21, and we actually managed to demonstrate a 
Telnet-like connection to SRI." 

3. This democratic community is in danger of being fundamentally 
altered. This study of the history of the development of the 
ARPANET in conjunction with my paper, "The Social Forces Behind 
the Development of Usenet News" are meant to help people 
understand where the Net has come from, in order to defend it, 
and try to fight to keep it open and democratic - the seventh 
wonder of the world as a recent ad called the Internet, 
rmsdirecte(LaE3t was - but correct any way. I hope to make this 
analysis avaifiSleTn RFC form as a comment on RFC 1000. ' 


APPENDICIES 


APPENDIX A: 

Network Working Group 4689 

RFC-3 April 1969 

Steve Crocker 
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UCLA 

DOCUMENTATION CONVENTIONS 


The Network Working Group seems to consist of Steve Carr of Utah, Jeff 
Rulifson and Bill Duvall at SRI, and Steve Crocker and Gerard Deloche 
at UCLA. Membership is not closed. 

The Network Working Group (NWG) is concerned with the HOST 
software, the 

strategies for using the network, and initial experiments with the network. 

Documentation of the NWG's effort is through notes such as this. Notes 
may be produced at any site by anybody and included in this series. 


CONTENT 

The content of a NWG note may be any thought, suggestion, etc. related to 
the HOST software or other aspect of the network. Notes are encouraged 
to 

be timely rather than polished. Philosophical positions without examples 
or other specifics, specific suggestions or implementation techniques 
without introductory or background explication, and explicit questions 
without any attempted answers are all acceptable. The minimum length for 
a NWG note is one sentence. 

These standards (or lack of them) are stated explicitly for two reasons. 
First, there is a tendency to view a written statement as ipso facto 
authoritati ve;;i5 id we hope to promote the exchange and discussion of 
considerablyTgssThan authoritative ideas. Second, there is a natural 
hesitancy to publish something unpolished, and we hope to ease this 
inhibition. 

FORM 

Every NWG note should bear the following information: 

1. "Network Working Group" 

"Request for Comments:" x 
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where x is a serial number. 

Serial numbers are assigned by Bill Duvall at SRI 

2. Author and affiliation 

3. Date 

4. Title. The title need not be unique. 

DISTRIBUTION 

One copy only will be sent from the author's site to" 

1. Bob Kahn, BB&N 

2. Larry Roberts, ARP A 

3. Steve Carr, UCLA 

4. Jeff Rulifson, UTAH 

5. Ron Stoughton, UCSB 

6. Steve Crocker, UCLA 

Reproduction if desired may be handled locally. 

OTHER NOTES 

Two notes (1 & 2) have been written so far. These are both titled HOST 
Software and are by Steve Crocker and Bill Duvall, separately. 

Other notes planned are on 

1. Network Timetable 

2. The Philosophy of NIL 

3. Specificadons for NIL 

4. Deep®: Documentation of HOST Software. 


APPENDIX B: Listing of first 50 or 100 RFCs 
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APPENDIX C: Listing of RFCs that are Comments: 

238 "Comments on DTP and FTP proposals" 

1453 A Comment on Packet Video Remote Conferencing and the 
Transport/Network 

47 BBN's comments on NWG/RFC #33 

489 Comment on resynchronization of connection status proposal 
684 Commentary on procedure calling as a network protocol 
176 Comments on "Byte size for connections" 

368 Comments on "Proposed Remote Job Entry Protocol" 

175 Comments on "Socket conventions reconsidered" 

151 Comments on a proffered official ICP: RFCs 123, 127 

535 Comments on File Access Protocol 

430 Comments on File Transfer Protocol 

65 Comments on Host/Host Protocol document #1 

692 Comments on IMP/Host Protocol changes (RFCs 687 and 690) 

224 Comments on Mailbox Protocol 

68 Comments on memory allocation control commands: CEASE, ALL, 
GVB, RET,RFNM 1970 August 31 
773 Comments on NCP/TCP mail service transition strategy 

38 Comments on network protocol from NWG/RFC #36 
44 Comments on NWG/RFC 33 and 36 

623 Comments on on-line host name service 

39 Comments on protocol re: NWG/RFC #36 

718 Comments on RCTE from the Tenex implementation experience 
141 Comments on RFC 114: A File Transfer Protocol 
127 Comments on RFC 123 
148 Comments on RFC 123 

582 Comments on RFC 580: Machine readable protocols 
393 Comments on Telnet Protocol changes 
385 Comments on the File Transfer Protocol 
607 Comments on the File Transfer Protocol 

624 Comments on the File Transfer Protocol 

696 Comments on the IMP/Host and Host/IMP Protocol, changes 
50 Comments on the Meyer proposal 

559 Comments on the new Telnet Protocol and its implementation 
513 Comments on the new Telnet specifications 
690 Comments on the proposed Host/IMP Protocol changes 
563 Comments on the RCTE Telnet option 
463 FTP comments and response to RFC 430 

40 More comments on the forthcoming protocol 

1111 Request for comments on Request for Comments: Instructions 

to RFC Authors 
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129 Request for comments on socket name structure 

614 Response to RFC 607: "Comments on the File Transfer Protocol" 

1018 Some comments on SQuED 

117 Some comments on the official protocol 

1000 THE REQUEST FOR COMMENTS REFERENCE GUIDE 

531 Feast or famine? A response to two recent RFC's about 
network information 1973 June 26 
463 FTP comments and response to RFC 430 

613 Network connectivity: A response to RFC 603 Network connectivity 
a 

response to RFC 603 

685 Response time in cross network debugging 
135 Response to NWG/RFC 110 
355 Response to NWG/RFC 346 
73 Response to NWG/RFC 67 

130 Response to RFC 111: Pressure from the chairman 

131 Response to RFC 116: May NWG meeting 
29 Response to RFC 28 

492 Response to RFC 467 

568 Response to RFC 567 - cross country network bandwidth 
603 Response to RFC 597: Host status 

614 Response to RFC 607: "Comments on the File Transfer Protocol" 

125 Response to RFC 86: Proposal for network standard format 

for a graphics data stream 1971 April 18 
555 Responses to critiques of the proposed mail protocol 
156 Status of the Illinois site: Response to RFC 116 
112 User/Server Site Protocol: Network host questionnaire responses 
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